home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94a.txt / 000069_icon-group-sender _Thu Mar 3 10:15:32 1994.msg < prev    next >
Internet Message Format  |  1994-08-19  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Thu, 3 Mar 1994 12:35:39 MST
  2. Message-Id: <m0pcFDg-000NAjC@epic.truevision.com>
  3. Date: 3 Mar 1994 10:15:32 -0500
  4. From: "Paul Scherf" <paul_scherf@gatormail-m.truevision.com>
  5. Subject: RE: file dates
  6. To: icon-group@cs.arizona.edu
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10. I think this sounds like a great chance for defining a library interface
  11. (collection of functions), that could be supported by many of the environments
  12. in which ICON is used. My opinion is that new language keywords are a bit much.
  13. I guess that makes me against adding keywords.
  14.  
  15. C (i.e. past history (-: ) effectively defines two collections of functions for
  16. dealing with time. One collection deals with calendar dates and times of day
  17. (e.g. "What was the time and date of lunch one week from now?"). The other
  18. collection deals with stopwatch time (for scientific timing of events). Leap
  19. seconds and leap days (these are decided by astronomers and relative positions
  20. of celestial bodies) and calendars that vary with time (different number of
  21. months in different years, these appear to be decided by politicians and
  22. religous leaders), make these two kinds of time difficult to integrate.
  23.  
  24. Since ICON is often implemented in C, maybe an ICON interface to the C
  25. libraries would be useful or even appropriate.
  26. _______________________________________________________________________________
  27. In article <5a-oml5.mengarini@delphi.com>,
  28. Will Mengarini  <mengarini@delphi.com> wrote:
  29. >but I think this is a very good point that it'd be useful
  30. >for the language to define keywords or functions for things
  31. >that can reasonably be expected to be present on most or all
  32. >implementations.
  33.  
  34. You have to way that against increasing the size of the language
  35. (bloating or creeping featurism).  If there is a way to do it without
  36. adding a language feature (which you have already stated is possible
  37. under MS-DOS, and I can think of ways to do it under Unix), then I'd
  38. lean against adding it as a feature.
  39.  
  40. >Can anybody name an Icon implementation for a system where
  41. >files are created & stored in a way that doesn't keep track
  42. >of both creation date & time, & last-change date & time?
  43.  
  44. That's still not enough to make it useful.  At a minimum, you would
  45. like to be able to compare dates (eg: is date1 later than date2).
  46. You'd probably wish to know the amount of time between two dates, and a
  47. way to compare it to the current date.  This would be highly machine
  48. dependent (does the machine keep track of timestamps to the nearest
  49. microsecond or to the nearest minute).  You'd probably want a standard
  50. textual representation to make it easy to create new dates to compare
  51. against.  But if you used something like &dateline as the standard
  52. representation, should you provide functions to fix the redundant
  53. fields (the day of the week can be calculated from the month day year
  54. combination, making it redundant)?  Would you add functions to add or
  55. subtract time to a given date?  Etc., etc.
  56.